At present, presence service, a communication service used to collect and publish presence information, is more and more widely used. Many people, including family members, friends, and strangers, may want to obtain presence information of people who use the presence service. Much of the presence information, however, is user's privacy. The presence service enables a user to search for chat partners and query the status of partners through various terminals, without being restricted by time and space. As a result, instant information exchange according to text and multimedia may be achieved. A presence server is used to present and manage the user status. According to presence information, a user may know information including whether another partner is online, what the partner is doing (for example, having a meeting or dinner), client capability, and so on. The user may send a request to other user to share media contents such as ring tone, picture and file.
FIG. 1 shows a schematic diagram of the system for providing presence service in prior arts. The system comprises the presentity client or the application server (103), presence server (102), watcher client (101), and presence XML document management system (XDMS) (104). The presentity client or the application server (103) is the source of presence information. When the presence information changes, the presentity client or the application server (103) sends a PUBLISH message to the presence server (102) to publish the present information.
The presentity client and the watcher client (101) may be mobile terminals such as mobile phone or personal digital assistance (PDA), or intelligent terminals such as digital set top box (STB). The above functions of mobile terminals may also be used in fixed terminals. At present, fixed terminals with function of the session initiation protocol (SIP) emerge. An application program publishing messages is available in the presentity client or the application server (103). A user selects and confirms the information to be published, then the presentity client or the application server (103) sends the presence server (102) all the information including user ID.
The presence server (102) receives SUBSCRIBE messages from the watcher client (101) and judges subscription result according to subscription authorization rules preset by the presentity client. The presence server receives PUBLISH messages from the presentity client, processes the messages according to rules (including content composition, authorization and filter) preset by the presentity client or the application server (103), and publishes the presence information to the watcher client (101) by NOTIFY messages.
The watcher client (101) subscribes to presence information of the presentity client or the application server (103) and receives the NOTIFY messages from the presence server (102).
The presence XDMS (104) stores authorization rules (eg, subscription authorization rules, content authorization rules, delegation authorization rules, etc.) of the presentity client or the application server (103), group list, etc. Other units such as presence information composing and publishing unit may directly access the XDMS (104) via XML document configuration and access protocol (XCAP), or obtain a series of information (eg, subscription authorization rules, content authorization rules, delegation authorization rules, etc.) from the authorization rules in the XDMS (104) by a special information access unit. The presence XDMS (104) may be merged with the presence server (102) or be placed as an independent service units accessed via a specified communication protocol.
The above SUBSCRIBE and PUBLISH messages are SIP messages. In a SIP message, PUBLISH message header contains presentity ID, and PUBLISH message body contains an XML document, which is presence information of the presentity. A SUBSCRIBE or PUBLISH message is not limited to an SIP message. In the IP multimedia subsystem (IMS) network, it is an SIP message, in other networks such as ICQ/MSN application in the IP network, it may be a private message. The presence server (102) comprises a most important unit refer to as the presence information composing and publishing unit (105) and FIG. 2 shows its schematic diagram. The presence information composing and publishing unit (105) comprises presence information composing unit (211), content authorization rules checking unit (212), watcher filtering unit (213), partial notification processing unit (214), and presence information publishing unit (215). The presence information composing unit (211) composes newly published presence information and presence information saved in the presence server. The content authorization rules checking unit (212) filters information and rejects information not permitted to be published according to rules set by the presentity client. The watcher filtering unit (213) filters information and rejects information not expected to be received according to rules set by the watcher client; for example, the watcher only wishes to be informed when a user get online and expects to reject other presence information. The partial notification processing unit (214) filters information and rejects the information beyond the scope of subscription according to the rules set by the watcher (101) during subscription; for example, the watcher only wishes to be informed presence information relating to location. The presence information publishing unit (215) notifies the watcher client (101) of the processed presence information. The connection sequence of the content authorization rules checking unit, watcher filtering unit, and partial notification processing unit may be set according to actual conditions.
FIG. 3 shows the interactive flow chart of a prior system. The detail is as follows:
1) Presentity client A sets some rules such as subscription authorization rules and content authorization rules in XDMS. The presence server may obtain the rules via XCAP, or by notification of changing of the rules from the XDMS if the presence server subscribes the notification of changing of the rules. The subscription authorization rules and content authorization rules are saved in an XML file, which includes three major elements, that is, Condition, Action, and Transformation. Condition indicates the match condition, and Action indicates the match result (eg. permit, reject, friendlily reject, confirm, etc.). The two elements are combined to represent the subscription authorization rules and process subscription requests from the watcher client according to the subscription authorization rules set by the presentity client. Transformation represents the content authorization rules, filters information and rejects the information not permitted to be published according to the content authorization rules set by the presentity client.
2) Watcher client B sends a subscription request to the presence server to subscribe to presence information of the presentity client.
3) The presence server matches the subscription request according to the subscription authorization rules in the XDMS. if the subscription request satisfy the subscription authorization rules, the presence server permits watcher B's subscription and saves subscription relationship of watcher B and presentity A.
4) Presentity client A publishes presence information to the presence server.
5) The presence server sends NOTIFY message carrying the presence information to watcher B, after processing the presence information according to a series of rules.
In the aforesaid arts, the XDMS is separated from the presence server, and all rules are saved in the XDMS. The presentity client sets or modifies rules in the XDMS via XCAP by aggregation proxy, or the application server sets or modifies the rules directly via XCAP, or presence user set or modify the rules through man-machine interface such as Web page. In prior arts, the XDMS and the presence server may be merged, and all rules are saved in the presence server. In aforesaid arts, the publisher of presence information must be the presentity client, which is not flexible enough and provides poor user experience. The aforesaid publication of presence information is called non-delegation publication. If other persons or devices are delegated to publish presence information on behalf of the presentity, the aforesaid defect may be avoided. For example, when user A logs in to the game server to play games, his presence status is “playing game” and the presence information of user A may include the game server name, game hall name, game name, etc. The user A wishes that the game server may be delegated to publish presence information for him so that his friends may obtain his status and log in to the same game server to play games with him. In this case, user A may not publish presence information manually. Another example: general manager of a company is going to hold a meeting and asks his secretary to set his status to “meeting”. The secretary publishes presence information of the general manager by using some software. Obviously, the user's experience is greatly enhanced through delegation.
Inventor found that in prior arts, however, the publisher of presence information must be the presentity client of the presentity and the system in prior arts could not publish presence information by delegation. In this case, users cannot delegate other entities to publish their presence information. They have to log in to another program to publish presence information themselves. As a result, users have poor experience and the mechanism is not flexible enough. When user uses some services, the service presence information may be very limited because user is not familiar with the services and does not know the presence information of the services.